Configurable default schema

Let the replicator module specify the default schema, instead of using a DEFAULT_SCHEMA const.

For postgres the 'public' schema is easy. However, for other source databases such as mysql or mongodb, we want to use the database from the connection string as the default, while possibly allowing other databases to be explicitly specified.

Flexible replication id

Let the replicator module compute the replica id for each operation, instead of auto-computing. This can now be persisted as any BSON-compatible value, instead of always converted to a v5 UUID.

Currently, for Postgres, we compute the replica identity as a hash (v5 uuid) from all replica identity columns, after converting to the SQLite format. However, we want the replica identity behavior to match the source database as close as possible, and we lose precision in this way. For example, the old approach would consider _id: ObjectId('66e834cc91d805df11fa0ecb') and _id: '66e834cc91d805df11fa0ecb' as equivalent, while MongoDB considers those as distinct ids. So the new approach allows any BSON-compatible value to be used, and the replicator module can decide what to use.

This does not change anything for Postgres yet.

Implementation notes

1. SyncRulesBucketStorage instances (BucketStorageFactory.getInstance()) doesn't include a parsed copy of sync rules by default. It is parsed on startBatch() instead, or by calling getParsedSyncRules(). This affects some other APIs as well.
2. For new-style replica ids, row subkeys now combine the table and replica id in a single UUID. For old-style (postgres) subkeys, this is kept as <table>/<replica id>. We may migrate the Postgres ones to the new smaller format as well in the future.